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Abstract. We propose Monoid , a design for a decentralised, authenticated and 
privacy preserving database for cryptographic keys and identity data. We designed 
it to meet both possible legal compliance requirements for cryptographic authenti¬ 
cation and integrity, as well as the demand for decentralised, trust-minimising key 
and credential distribution for digital identity. 



1 Introduction 


In a sense, communication networks can be defined 
entirely by who has cryptographic keys. 

Whitfield Diffie (Cryptographer) 

Most security protocols and analyses of those assume trust in a particular entity in 
their network ontology, which distributes keys for a given entity. In the following, 
we will propose primitives, frameworks and procedures for the Monoid. Our 
proposal aims to contribute to overcome the tmst-problem induced by the premise 
of third-party-trust. We aim to contribute in high generality, i.e. from a perspective 
where we consider the following as ontologically equivalent : 

rrust anchors. Certification authorities (CA’s) for X.509 certificates, DNS root 
servers for TLSA records, PGP-Key servers are - in a sense - ’trust anchors’ in their 
corresponding cryptographic trust-ontology. Trust is ’rooted’ in their integrity, 
as they are authoritative for some bindings of keys to identities. Usually this 
role manifests in form of a trusted public-key-infrastructure (PKI) which aims to 
guarantee two properties for the keys utilised in later applications: authenticity 
and integrity. Yet, there is no rigorous reason to trust in ’trusted third parties’, i.e. 
a CA or a key server, besides common sense and belief. In contrast, there is often 
no mechanism available to audit the key bindings for other parties, i.e. to validate 
their assumptions regarding authenticity and integrity of the cryptographic back¬ 
bone hold. We find these assumptions to be unjustified for two reasons: 
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i. The security measures undertaken by a trusted third party are usually not 
publicly available, therefore intransparent. Key servers, CAs or identity providers 
are black boxes; when using a particular network, (locally) generated key data 
from one client is signed and transferred to a central entity. Later on, when other 
clients retrieve a particular key from a server, one has no way to be sure of its 
integrity. 

ii. It is not traceable wether or not a trusted third party is malicious and/or 
compromised. Quite the opposite is often the case: CAs have economic incentives 
to keep failures and flaws a secret. 

iii. From a network topological viewpoint, any centralised PKI has an inher¬ 
ent single point of failure which is a distinguished target vector for an attack, 
as a compromised key server is an ’ideal’ Man in the Middle. Therefore when 
protocols utilise a PKI, key servers are a security bottleneck; a protocol can be no 
more secure as it’s corresponding key serving entity. 


1.1 RELATED WORK. 

We give an overview of recent related proposals, which aims to provide a consistent 
and secure distribution model for cryptographic key material. While the related 
systems differ widely, they all aim - more or less - to securely distribute bindings 
of the form: 

I —> 7C, where 'K is cryptographic key material - usually public keys - and I is 
an abstract representation of an entity/identity, i.e. an IP- or an Email-Address, a 
username, pseudonym or a generalisation thereof. 
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NAME SYSTEMS. 

DNS SEC A!]] adds some security features to the DNS; while it mitigates some 
known weaknesses (i.e. cache poisoning and unauthenticated DNS responses), 
especially the distribution of DANE’S TLSA records via the DNS inherit attack- 
vectors from the authoritative approach the DNS took, such as DoS and the 
possibility of compromised roots. 

NAMEID 0 is based on NAMECOIN’s [03 shared high integrity identity ledger, 
which implements Bitcoin’s PoW mechanism. Until today, no successful major 
attacks on either Bitcoin or it’s offspring have been reported. However, Namecoin 
suffers from similar issues as Bitcoin, i.e. little scalability, wasted resources and 
the lack of authentication. 

The GNU NAME SYSTEM (GNS) 0] implements a Rsn [0] hash-table as a 
decentralised, censorship-resistant ledger to securely store and distribute zone- 
records. In contrast to the DNS, GNS entities are self-authoritative; Entities may 
use ’pet names’ - i.e. arbitrary key-value bindings - for their name-zones and 
delegate authority over sub-spaces to other entities they tmst. The GNS aims to be 
able to replace both, the DNS as a name system and as a distribution mechanism 
for puplic-key material. Additionally, the name resolution mechanism is privacy 
preserving and encrypted symmetrically, ruling out the possibility to enumerate 
the name space, which is a privacy issue in the DNS protocol and an inherent 
problem in Namecoin’s public ledger.. 

However, GNS does not give any guarantees on the integrity of the bindings stored 
in the distributed R$n hash-table. GNS’s trust-ontology is similar to the WoT; 
Nodes are - in general - unauthenticated, therefore name-spoofing and attacks 
on the decentralised resolution mechanism - including equivocation - may be 
possible. Therefore, the GNS is - for now - not compliant to current standard 
regulation. 
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OTHER APPROACHES TO ESTABLISH TRUST TO IDENTITY. 

CERTIFICATE TRANSPARENCY @ provides a publicly auditable append-only 
log for X.509 TLS certificates. Information stored in this log is distributed to 
clients by monitors, ran by certification authorities. Therefore, there is no abstract 
entity added to its trust ontology, as the log servers are controlled by the certificate 
authorities themselves. 

NICKNYMs Q approach is a combination of TOFU and X.509, together with no¬ 
tary servers (CAs), forming a federated web-of-trust (WoT) with a non-equivocation 
mechanism that users can query. Besides internal failures or compromised no¬ 
taries, it is - for today - prone to enumeration attacks and DoS on Nym-servers. 
KEYBASE [0 introduces social validation via social media accounts. Users pub¬ 
lish statements about their key bindings through different social media channels; 
if later other users want to gather evidence for the correctness of these bindings, 
they can query a server, that answers with the ’site’s global state’. From this 
state, the querying user learns the location of the resources she needs, in order to 
gather evidence for some other nodes key-binding, which is in question. Thus, a 
compromised Keybase server can potentially fork the site’s state and equivocate 
about a key binding. 

UPORT m aims to introduce secure identities via identifiers - addresses of so 
called proxy ’smart contracts’ - stored in the Ethereum blockchain, able to interact 
with other ’smart contracts’. Additionally, Uport aims to use IPFS as an off-chain 
registry for identity data. Identities are able to act as a self-sovereign certificate 
authority, introducing similar attack vectors to Uport as are applicable to Name- 
coin, caused by its lack of authentication and accountability (i.e. name spoofing 
and fake ID’s, lack of legal compliance). 

U-PROVE IfTTHl proposed a cryptographic token, generalising and strengthening 
the concept of a cryptographic certificates. Ontologically, U-prove knows three 
different roles; Issuers, provers and verifiers. Issuers have the same role as certifi¬ 
cation authorities - being the trust anchor of the tokens they issue - while provers 
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are common users, that intend to generate a credential to prove certain claims 
about their identity towards a verifier (i.e. an online service, etc.)- While U-prove 
guarantees certain cryptographic properties, such as untraceability, unlinkability 
and selective disclosure of tokens, it assumes secure distribution of issuer’s public 
keys (as it is done today with CA root-keys) and is not concerned with issuers 
equivocating about user identities towards other users or verifiers. 

CONIKS mi retains the notion ’of service providers issuing authoritative name- 
to-key bindings within their namespaces’ (CA’s) as well, but extends the trust 
ontology in the following way; users are enabled to verify consistency of their 
key bindings with a proof of consistency - extending the function of certificates - 
which were distributed by identity providers. However, Coniks assumes, just as 
U-prove, a separate PKI for identity providers keys, leading into some security 
regress, i.e. the hen-or-egg problem. Central identity providers create a decided 
attack vector: From inside, via authoritarian decisions or compromises, as well as 
DoS. While Coniks enables users to detect the former at a later point in time, it is 
not able to ’deter a service provider from attacking its users openly’. 
CLAIMCHAIN [1T21| is a functional abstraction of standard certificates, similar to 
U-prove tokens, but with a more user centric network-ontology, especially tailored 
to deliver privacy preservation to an identity system. The stmcture enables general 
claims to be made by users about themselves or each other, in particular about 
their respective key material. Claimchain’s verification mechanism is not specified, 
it can therefore be deployed with different schemes, ranging from traditional CA’s 
to WoT. Its security properties are highly influenced by this particular choice. 
SOVRIN HHII has proposed a ’public permissioned ledger’ for user identity 
data. It follows the idea of a federated WoT, operated and administrated by 
the Sovrin Foundation. It aims to deploy a blockchain derivative that is permis¬ 
sioned, i.e. there’s a decided amount of so called ’trustees’ and ’stewards’, that 
reach consensus on the state of the ledger, following a modified version of the 
RBFT iTra protocol. Claims on identities are stored with tokens as described by 
U-PROVE, where ’stewards’ correspond to ’issuers’ in Uprove’s diction. Due 
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to its semi-federated organisational structure, it has similarities to the DNS, and 
therefore could - if deployed at a large scale - raise similar tech-political ques¬ 
tions. 


1.2 OVERVIEW. 

Contribution. 

Our proposition is well understood as a collage; we arrange several proposals from 
past years to synthesise^] a general framework for a decentralised identity ledger 
- the Monoid - tailored to introduce strong integrity and authenticity to digital 
identity in a decentralised manner. Especially, we aim to tie together some loose 
ends, i.e. we bridge approaches taken by the ’blockchain community’, regulatory 
demands, together with recent proposals from the scientific computer-science and 
cryptography discourse. 

Design goals. 

i. Integrity. | Equivocation about identities is hard, for both, external adversaries 
as well as for the entity controlling the identity. 

ii. Trust - minimising. | Discovery of other’s identities is easy and requires a 
minimal amount of trust in other parties. 

iii. Checks and balances. | Entities are enabled to proactively shape their identity, 
contribute in the systems trustworthiness and repel attacks with ease. 

iv. Privacy. | Interaction does not leak any unnecessary information. Social graphs 
are unobservable for eavesdroppers. 

1 Philosophically, we follow G.W. Hegel’s principle of Dialectic Aufhebung, to propose a 
framework for identity authentication and integrity protection, puzzling together different 
notions. 
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Approach. 

We now give an overview of our architecture and fix key features of our proposal. 
With Monoid, we follow the concept of a distributed ledger for cryptographic 
identities, enabling integrity protection and secure authentication, both in a decen¬ 
tralised manner. 

In general, the Monoid is a distributed Merkle tree. As a distributed ledger, it 
has similarities to blockchains and distributed hash tables. In contrast to the 
usual blockchain procedure, we describe a protocol for consensus we call ’par¬ 
tial weighted proof of identity’ (PWPOI), a reputation-system-based consensus 
mechanism, with the goal to adapt to experiences that have been made with recent 
constructions for decentralised ledgers: 

a. S cat-ability : The PoW consensus mechanism does not adapt to a large number 
of users easily. As an increased number of users does usually not come with a 
proportional increase in the systems resources, PoW converges towards centralisa¬ 
tion, besides other downsides. 

b. If write privileges are granted to easily, integrity suffers. This has happened 
to early peer to peer networks, i.e. bit torrent. This could as well happen to Name- 
coin, as arbitrary names may be registered without authentication. 

Our PWPOI mechanism aims to solve these two problems, i.e. it is a scalable 
method for decentralised consensus, tailored to use identity authentication as a 
’stake’ for an identity system. It is ’partial’, in the sense that nodes are assigned 
parts of the Monoid to watch and gossip on, depending on the resources they have 
access to. We define a metric, that may be used to compute ’weights’ correspond¬ 
ing to the amount of influence a given nodes ’gossip’ on the Monoid's (-partial) 
state has on other nodes perspectives of the Monoid's state. Nodes then interact 
in a gossiping protocol to gather evidence in order to determine the Monoid' s 
state. 
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Scope and limitations: 

We aim to describe the macroscopy of a shared ledger, the Monoid , and corre¬ 
sponding mechanisms. We assume that the role of a privacy preserving identity 
data structure (PPIS) is already filled by a data structure such as described in 
Claimchain or Uprove 

Monoid's role in the security pipeline is that of a decentralised high-integrity 
key-value store, where keys are cryptographic public keys and values are hash 
digests, corresponding to and derived from the PPIS of certain entities. 
Additionally, the PWPOI consensus mechanism is based on multiple authenti¬ 
cations and therefore also contributes a explication of the ’social verification 
mechanism’, Claimchain did not specify so far. 

However, while we give mathematical definitions and formalisations to some 
extend, our proposal will often remain abstract; i.e. it falls short to give details, 
especially with respect to implementation. 
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2 PRELIMINARIES 


2.1 NOTATION. 

Hash functions. With rj(X) we denote the cryptographic hash of data X. 

Encryption. With S £j (X) we denote the cipher text of plaintext X with respect to 
a cipher 8 and a key e;. 

Decryption. With Ds^X) we denote the decipherment of 8> fj (X). Note that 
€i and Si do not differ necessarily. 

S ignatures. As a signature S £i (X ), we denote the tuple (£ e . ( 77 (A)), D, Si, X). 


2.2 ASSUMPTIONS. 

a) random oracle model: rj is pre-image resistant and collision resistant. 

J3) forgery resistance : <p(S £i (X )) = X for some functon f if and only if f = D () , 

y) authentic entities. In a network, the majority of ‘authenticated 4 entities does 
not affect the network adversely. 
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2 preliminaries. 


2.3 DEFINITION AND PROPOSITION. 
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Fig. 2.1 : Illustration of a r-tree 


Definition 1. Let (Si, Xi)i & jsj be a series of pair¬ 
wise distinct public keys and corresponding 
(identity-) data. A r-tree r is a recursive series 
(t/)/gn of hash values defined as follows: 


to = ^(boll^o) 
t/+i = rj(Ti\\6i\\Xi) 


Proposition 2. r is a directed acyclic Merkle- 
Graph 

Proof. Let V = {r,- | i e N} be the 
set of vertices of r. The set of edges 
is then given by all ordered pairs E = 
{{r/, p(ri\\6i\\Xi} | i e N} = {{t/,t;+i} | i e 
N}. Assume 3 E c c E, s.t. E c = 


{{Tj, Tj+u }, [Tj+ 1 Tj+ 2 },..., { T j+k , rj+i,} | j € J c N}. This gives us: 

77 (ry 11(5/11A’y= 77 (ry-j-fc|Il-^y+A:) in contradiction to assumption a). Therefore r 
is acyclic. 


□ 


Remark. This short proof of r being acyclic implies, that if a series of r-trees 
(Tf)fej a H have current final hash value r/, then r, = tj, Vi, j € J. The converse 
is true as well. This observation gives us: 

(<5,-,<Y;); e ]N consistent ry consistent. 
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2 preliminaries. 


Definition 3. Let (r;),-= n even, be a series of pairwise distinct r-trees with 
final hash Tfj. Then depicts entries of order j and position k in the Merkle- 
tree M generated from Tfj. We call M a which is defined as follows: 


MU =Tj(Tf,0\\Tf,l), ^(t/,2||t/, 3 ), • • • , ^(t/,„-3||t/ ; „_ 2 ), 77(r/,„_l||T/,„) 

M,A: = ?7(M),ollMu)> • • • >?7(M),§-illM),f) 

1,A ||Wl; n —2,2)5 2,31—2,4) 

1,1 1 —12) 

Remark. M is a slightly altered Merkle-tree. Therefore, its immutability can be 
reduced to the integrity protection of M m , which can be shown analogue to the 
proof of Proposition 2. 


1 not in the algebraic sense, as hashing is non-associative 
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3 core: authenticity 


INTEGRITY 


The definition of r-trees in the last chapter was intended to create an immutable 
distributed data base to store values, representing identities (i.e. claimchains or 
U-prove tokens) together with their corresponding public keys. 

We gave a proof, that immutability and - as a result - integrity of the stored data 
is reducible to integrity of one hash-value. We therefore envision the following 
general construction for the Monoid, based on recursive hashing: 


chains 


claimchain, u-prove token 


n 

-> 


t - trees 
Def. l 


n 

-> 


Monoid 
Def. 3 
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3 core: authenticity / integrity 


3.1 INTEGRITY. 


Next, we describe a partitioned 
and decentralised network to 
distribute the Monoid, giving 
participating entities access to 
the keys. The proposed de¬ 
sign is depicted in the figure 
on the left. We tailored it to 
approach the following design 
goals: 


i. Equivocation about identi¬ 
ties is hard, for both, external 
adversaries as well as for the 
entity controlling the identity. 

ii. Discovery of other identi¬ 
ties is easy and requires a min¬ 
imal amount of trust in other 
parties. 

Abstractly, the r-tree data structure - if suitably distributed - would be sufficient 
to reach these design goals. This approach was taken with blockchain-designs, 
yielding their scalability issue. In order to overcome this obstacle, we decided to 
take a partitioning approach, i.e. to distribute the Monoid data structure partially. 
We only give a sketch of the partitioning. 

In general, nodes are ordered by the amount of resources at their disposal and 
the size of the partition of the Monoid they are able to process: For convenience. 



Fig. 3.1 : The distribution of the Monoid. 
Only nodes of Oth order and nodes of 
1st order depicted, while there may be 
nodes of higher order in general. 
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3 core: authenticity / integrity 


we consider only two types of nodes in two layers, populars and ladder^ while, 
in general, additional layers may be introduced to increase the fragmentation if 
necessary. 

populars | o th order. Popular nodes are both subscribers and publishers of the 
current state of a particular subset of trees t ;, representing consistently stored data 
in a subset of the network. Nodes are able to audit the Monoid by checking the 
integrity of the key-value bindings in their partition by verifying r/. They further 
periodically sign and publish the current r-values of their partition of the Monoid 
to other nodes. Therefore, every peer has a maximal amount of different and in¬ 
dependent sources for both the r-trees and the corresponding key and identity data. 

ladders \ 1 st order. If machines have enough resources to process the data gen¬ 
erated by all subnetworks, they may become a ladder node. They live in the 
intersection of all subnetworks and therefore operate as a popular node in any 
subnetwork. They additionally use the same procedures as nodes of lower order 
to compute the Monoid from r-trees and negotiate consensus among each other 
as well. 

Remark. Both layers are unable to equivocate about the Monoid's state, as they 
mutually audit each other. If additional layers were introduced in between, this 
would further strengthen the auditing mechanism. 


1 The diction ’ladder node’ is derived from a notion of L. Wittgenstein in the following sense: 
Centralised nodes fulfil the purpose of a ladder and may become unnecessary at a later point in 
time, ’the ladder may become exposable after climbing with it’. I.e. we favour decentralisation 
but utilise central nodes for authentication - mainly for legal and governmental reasons -, but 
as well to increase scalability and availability. 
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3.2 AUTHENTICITY. 

A person is a person through other persons. 

Proverb, Ubuntu philosophy lfT5l 

The draft we described so far, is prone to sybil attacks and name spoofing. Our 
approach against this kind of attack is identity authentication, i.e. certificates 
from ’trusted’ parties of some kind. As stated in premise y, we assume that if 
nodes are controlled by authenticated entities, a majority of them will not affect 
the network adversely. Further, authentication is for many applications of digital 
identity required by law (i.e. digital signatures in e-gov). Authentication to just one 
party is the theoretical minimum required to have any authentication in a system 
at all. 

Usually, profound ways of authenticating a party’s identity rely on tokens and 
certificates issued by (governmental-) trusted third parties, serving as trust-anchors 
(i.e. passports). Our architecture entails this model, but in contrast, we envision to 
invert the burden of proof in the following sense: authentication of new nodes 
with a ladder node is a requirement in order to write an identity to the Monoid. 
Yet, we depict nodes in the ladder layer as mistrusted third party, i.e. this authen¬ 
tication is to be verified in order to accumulate tmst by other (popular-) nodes. We 
will further describe this notion of authentication, model it in a ’mistrust metric’ 
and the PWPOI mechanism for consensus in the following sections. We aimed to 
reach the following design goal: 

iii. Checks and balances. | Entities are enabled to proactively shape their identity, 
contribute in the systems tmstworthiness and repel attacks with ease. 
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3.2.1 MISTRUSTED THIRD PARTIES | BOUNTY HUNT 

We give a sketch of an authentication framework, that entails the current trusted 
third party model. Generally speaking, we invert the the burden of proof: Au¬ 
thentication (signatures on key-value bindings stored in the Monoid ) issued by 
third parties (the ladder nodes in our diction) are accepted and potentially legally 
binding, but not trusted. The mistrusted third parties are now assigned the task 
to enhance the trust in the validity of their authentication. In order to do so, they 
start a bounty hunt. This yields a procedure for authentication^ that synthesizes 
and incentivizes two common authenticity models: certification authorities and 
the web of trust. 


i) An entity N gets authenticated via a certificate, worth a bounty S, by a ladder 
node X- For this authentication X receives 50% of the bounty S. 

ii) In the following, the remaining 50% of S get utilized as an incentive for 
peers to iteratively re-authenticate N and audit the authentication of X- & gets dis¬ 
tributed in a slowly converging series among k bailers , for instance as geometric 
series S k = J[, s.t. J* =l & k » S. 

Remark. In theory, this procedure converges towards optimal authentication 
(i.e. full mutual authentication with every other node) and only terminates 
for an infinite number of verifiers, but is practically bound by n - 1 possible 
authentications and - even more so - by the fast decreasing incentive for new 
bailers. 


2 While the analogue measures for authentication are crucial, they are outside of our scope. 
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3.2.2 AUTHENTICATION-GRAPH | AUTHENTICATION-METRIC. 

We now specify the model and terminology of Monoid's mechanisms for authenti¬ 
cation and consensus, assuming authentication occurs within the framework we 
sketched. In general, our approach is to link authentication to consensus, accord¬ 
ing to premise y. We specify a non-binary reputation metric in order to compute 
weights for a nodes gossip on the current state on (a partition of) the Monoid. 

heuristics. We define a metric g, that aims to model the following heuristics 
with regard to mistrust of authentication among a set of entities: 

i) Mistrust increases, as a path of trust grows longer from one entity to another. 

ii) Mistrust decreases with the amount of mutually familiar entities on a path. 

iii) Mistrust decreases, with the amount of dis joint paths of trust from one entity 
to another. 

These heuristics motivate the following definitions: 

Definition 4. authentication graphs. 

Consider a set of nodes N, i = 1,..., k. Let there be an edge e = (x,, Xj) Xi -t Xj e 8 
between two nodes iff Xj and xj are mutually authenticated. This defines an 
undirected graph Q = (fV, 8). 

Definition 5. authenticated networks. 

Consider an edge e = (x,y) x ± y € 8 and the closed neighbourhood of a node 
Ng[x\. We define: 

//:£-> [ 0 , 1 ], 

(X ' y) "* lAfeWnAfeMl 


The triple ( v V, 8,p') is a weighted graph or a network. We now enrich p’ to 
receive a metric on Q. 
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Definition 6. mistrust - metric. 

Let be U XJ be the set of all paths from x to y in Q. If H x y ± 0, let be 

: = argmin ^ /*'(«)> 

n x,yEtI X ,y e€.JI x ,y 

i.e. a shortest path with highest degrees of authentication from x to y. We define 
p : *V x Y —> IR to receive a metric as follows: 


p(x,y) = 


0 


re 


, if x = y 


, if x±y 


Proof. Non-negativity follows, as only positives are involved. Identity follows by 
definition. 

For symmetry consider: x, y € V with II XJ p 0. We get TL XJ = 1 l yx and therefore 
<V = argmin Z^ XJ p'(e) = argmin p'(e) = /r* x 

Let be x,y,z £ r V. We have 




KJ ^ K,y\{Zeen^ y P'(e)) |< J (Z 


in 


< 


e€ <z V 


0) 


X,zl 


in XJ i 

= +/*(y,z), 


\ U y,z 


as 



f \ 

1 

f S 

1 1 

f \ 


Y 

VI 

Y v( e ) 

y e€7T iy , 

+ 

A 

Y v'( e ) 

< ee7r y,z j 


n xy i C (Yl x y n fTy^) . 


Thus, (Y, &,p) is a metric space. □ 
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3.3 CONSENSUS | ACCOUNTABLE GOSSIPING. 

For consensus, we envision a combination of an epidemic algorithm [fTfif) . a 
forward-secure, identity-based multi-sign scheme (IBMS) as in ifTTll together with 
the mistrust-metric g we defined in the last section. 

We depict it as accountable gossiping or partial weighted proof of identity (PW- 
POI). Entities W, with access to the Monoid periodically sign the current r values 
they are auditing and publish it to other nodes. A gossip on the state of a r-tree is 
then multi signature of the form . €n (t>). 

INTRA-PARTITIONAL CONSENSUS. 

Nodes, that receive gossip from other nodes, which are auditing the same partition 
of the Monoid , have all information at their disposal, that is necessary to check 
the validity of the signatures. 

i) They periodically compute 7y for the state of their partition and compare it to 
other gossip they receive. 

ii) If no inconsistencies are detected, they accept the gossip on the current state of 
t>, use the 1BMS to sign what they received in the previous step with their own 
private key and republish the result. 

iii) Else, they reinitialise the procedure with their current r value and publish a 
concurrent gossip. 

iv) Eventually, after a time to be specified, some hash t> receives the major¬ 
ity of signatures and is considered trustworthy. 
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INTER-PARTITIONAL CONSENSUS. 

Nodes, that receive gossip from other nodes, which are auditing a different parti¬ 
tion of the Monoid , do not have all information at hand, that is necessary to check 
the validity of the signatures. However, there’s is at least one authentication-path 
to every other node, due to the obligatory authentication with a ladder node. We 
further assume, that they have the ability to compute the authentication network 
(Definition 5). Nodes are then able to gather evidence regarding the state of the 
Monoid outside of their partition as follows: 

i) If a node receives gossip from other nodes outside 0] of their partition, it com¬ 
putes its own mistrust towards the publishing node as in Definition 6. 

ii) Optionally, a node has the ability to compare the gossip published by popular nodes 
with the gossip of ladder nodes, if she chooses to prioritise them as trusted 
sources. 

iii) In any case, a node X chooses to trust the state of the Monoid it has most evi¬ 
dence forj^jwith respect to the mistrust - metric and its choice in ii). 


3 if the publisher and the subscriber audit partitions of the Monoid with non-empty intersection, 
the receiving node first verifies the correctness of they key-value bindings in the intersection. 
If it detects an inconsistency, the gossip is to be disposed. 

4 i.e. the gossip *S eij ... ; g n ( t>) from nodes xi ,..., Xk where xf) is minimal. 


20 



4 SUMMARY. 


4.1 CONCLUSION. 

After briefly sketching our trust-ontology and specifying our assumptions, we 
have described the Monoid, a decentralised ledger for digital identities with strong 
integrity and authenticity protection. We gave definitions for all required build¬ 
ing blocks which are necessary to construct the Monoid ledger and sketched a 
layered decentralised architecture to distribute it. We further gave high-level 
descriptions of procedures for integrity, authentication, to establish trust and 
consensus. However, we did not give any specifics with respect to implementa¬ 
tion. 


4.2 FUTURE WORK. 

We aimed to make our premises transparent and give definitions and proofs with 
some rigour. However, our proposal fell short of several aspects we want to 
address in the future: 

First, we assumed that the majority of authentic entities in a network does not 
affect the network adversely (y ). This assumption is speculative and hard to model 
rigorously. It is based on the notion of authenticity, which is to our knowledge, 
an unanswered question more of philosophical nature. A future line of argument 
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should therefore be an empirical examination of the validity of this premise. 
Before implementational choices are made and evaluated, we will contribute more 
theoretical work, i.e. define an adversary model, state security propositions and 
proofs thereof. 

Further, we described the distribution and the auditing of the Monoid, which 
require partitioning it for scalability. Yet, while the partitioning mechanism may 
have severe implications - including but not limited to security - we did not give 
any specifics on how partitioning should happen. A next step therefore is imple¬ 
menting the Monoid as a distributed hash table, i.e. with Kademlia IfTRlil or more 
advanced distributed-hash-table algorithms such as R$n Q. 

The particular implementation also impacts another problem, that our draft as¬ 
sumed to be solvable; access and computability of authentication graph. In our 
proposal we assumed a ’birds eye view’ for every node, i.e. full knowledge of the 
authentication graph and computational feasibility of the algorithms necessary to 
compute the values of the mistrust-metric \i. An implementation - for instance 
with A* - could indicate, if design changes are necessary. 

Another open aspect is how in particular authentication of new nodes should 
take place; there are many different approaches to this problem and it is an open 
research questions, ranging from manual hash-fingerprint comparison to whole 
scientific fields (i.e. biometrics). We do not aim to specify the particular measures 
undertaken for authentication; while they are critical, they are interchangeable in 
our model. 
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BLOCKCHAINS. 


The ledger we proposed has similarities to the original Bitcoin-Blockchain l1T9ll . 
but favours a one vote per node over one vote per CPU paradigm for consensus. 
This yields a trade-off; it allows sybil attacks, where a large group of adversary 
machines compromises the consensus mechanism by outvoting. This issue is tack¬ 
led by our setup in several ways: First, the network is partitioned and replicated as 
described earlier. Second, our design works with authentication, a cryptographic 
property that was later forced into blockchain environments (i.e. today, before 
able to buy Bitcoins, users are often legally obliged to analogously authenticate 
to a third party). We opt out from Bitcoins pseudonymity and introduce authen¬ 
tication. Although this is a drawback regarding Zooko’s Triangle, we consider 
this the best option, as todays laws usually require a certain amount of identity 
validation before intensive application is permitted. Our design therefore tries to 
find a reasonable compromise between the central authentication required by law 
and as most decentralisation and privacy as possible for an identity system to be 
deployable on a large scale. 

Yet, the biggest advantage of favouring the one vote per node paradigm is in our 
opinion, that it removes the necessity of mining new blocks via proof of work, 
which is an intentional and inherent blockchain inefficiency that increases over 
time together with the difficulty of the proof of work. We find a few inherent 
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drawbacks that mining brings with it; first, it is an obvious and intentional waste of 
CPU power, that could otherwise be utilised elsewhere. It is also a waste of energy 
and therefore of environmental resources, which isn’t and may never will be a 
good foundation to build the backbone of modern infrastructure on. Last, many 
blockchain based networks centralise themselves over time; as mining becomes 
more and more difficult, the incentive for individual and independent mining 
decreases. Miners collaborate to have better chances to get rewarded, while it 
is out of the reach of the protocol to regulate who controls the mining pool. We 
sketched a decentralised incentive, that strengthens the systems trust while actually 
contributing useful work: Authentication. 
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